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Title: Diagnostics in a Process Control System which uses Multi-Variable 
Control Techniques 

Description of Invention 

The present invention relates generally to process control systems and, 
more particularly, to the automatic detection of problems existing within 
function blocks, devices and loops which use multi-variable control techniques 
within a process control system. 

Process control systems, like those used in chemical, petroleum or other 
processes, typically include a centralized process controller communicatively 
coupled to at least one host or operator workstation and to one or more field 
devices via analog, digital or combined analog/digital buses. The field devices, 
which may be, for example valves, valve positioners, switches and transmitters 
(e.g., temperature, pressure and flow rate sensors), perform functions within the 
process such as opening or closing valves and measuring process parameters. 
The process controller receives signals indicative of process measurements 
made by the field devices and/or other information pertaining to the field 
devices, uses this information to implement a control routine and then 
generates control signals which are sent over the buses to the field devices to 
control the operation of the process. Information from the field devices and the 
controller is typically made available to one or more applications executed by 
the operator workstation to enable an operator to perform any desired function 
with respect to the process, such as viewing the current state of the process, 
modifying the operation of the process, etc. 

In the past, conventional field devices were used to send and receive 
analog (e.g., 4 to 20 milliamp) signals to and from the process controller via an 
analog bus 30 or analog lines. These 4 to 20 ma signals were iimiied in nature 


in that they were indicative of measurements made by the device or of control 
signals generated by the controller required to control the operation of the 
device. However, in the past decade or so, smart field devices including a 
microprocessor and a memory have become prevalent in the process control 
industry. In addition to performing a primary function within the process, 
smart field devices store data pertaining to the device, communicate with the 
controller and/or other devices in a digital or combined digital and analog 
format, and perform secondary tasks such as self calibration, identification, 
diagnostics, etc. A number of standard and open smart device communication 
protocols such as the HART®, PROFIBUS®, WORLDFIP®, Device-Net®, 
Profibus, AS-lnterface and CAN protocols, have been developed to enable 
smart field devices made by different manufacturers to be used together within 
the same process control network. 

Moreover, there has been a move within the process control industry to 
decentralize process control functions. For example, the all-digital, two-wire 
bus protocol promulgated by the Fieldbus Foundation, known as the 
FOUNDATION™ Fieldbus (hereinafter "Fieldbus") protocol uses function 
blocks located in different field devices to perform control operations 
previously performed within a centralized controller. In particular, each 
Fieldbus field device is capable of including and executing one or more 
function blocks, each of which receives inputs from and/or provides outputs to 
other function blocks (either within the same device or within different 
devices), and perlorms some process control operation, such as measuring or 
detecting a process parameter, controlling a device or performing a control 
operation, such as implementing a proportional-derivative-integral (P1D) 
control routine. The different function blocks within a process control system 
are configured to communicate with each other (e.g., over a bus) to form one 
or more process control loops, the individual operations of which are spread 
throughout the process and are, thus, decentralized. 


With the advent of smart field devices, it is more important than ever to 
be able to quickly diagnose and correct problems that occur within a process 
control system, as the failure to detect and correct poorly performing loops and 
devices leads to sub-optimal performance of the process, which can be costly 
in terms of both the quality and the quantity of the product being produced. 
Many smart devices currently include self-diagnostic and/or calibration 
routines that can be used to detect and correct problems within the device. For 
example, the FieldVue and ValveLink devices made by Fisher Controls 
International Inc. have diagnostic capabilities that can be used to detect certain 
problems within those devices and also have calibration procedures that can be 
used to correct problems, once detected. However, an operator must suspect 
that a problem exists with the device before he or she is likely to use such 
diagnostic or calibration features of the devices. There are also other process 
control tools, such as auto-tuners that can be used to correct poorly tuned loops 
within a process control network. Again, however, it is necessary to identify a 
poorly operating loop before such auto-tuners can be used effectively. 
Similarly, there are other, more complex, diagnostic tools, such as expert 
systems, correlation analysis tools, spectrum analysis tools, neural networks, 
etc. which use process data collected for a device or a loop to detect problems 
therein. Unfortunately, these tools are data intensive and it is practically 
impossible to collect and store all of the high speed data required to implement 
such tools on each process control device or loop of a process control system in 
any kind of systematic manner. Thus, again, it is necessary to identify a 
problem loop or a device before being able to effectively use these tools. 

Each device or function block within a smart process control network 
typically detects major errors that occur therein and sends a signal, such as an 
alarm signal or an event signal, to notify a controller or a host device that an 
error or some other problem has occurred. However, the occurrence of these 
alarms or events does not necessarily indicate a long-term problem with the 


device or loop that must be corrected, because these alarms or events may be 
generated in response to (or be caused by) other factors that were not a result of 
a poorly performing device or loop. Thus, the fact that a device within a 
process control system or a function block within a control loop generates an 
alarm or event does not necessarily mean that the device or loop has a problem 
that needs to be corrected. On the other hand, many devices can have problems 
without the problem rising to the level of severity to be detected as an alarm or 
an event. 

To initially detect problems within the process control system, a process 
control operator or technician generally has to perform a manual review of data 
generated within a process control system (such as alarms and events, as well 
as other device and loop data) to identify which devices or loops are operating 
sub optimally or are improperly tuned. This manual review requires the 
operator to have a great deal of expertise in detecting problems based on raw 
data and, even with such expertise, the task can be time-consuming at best and 
overwhelming at worst. This is especially true for multi-variable control blocks, 
such as neural network or other multi-input control blocks, which are very 
complex in nature and in which problems are even more difficult to detect. As 
one example, an instrumentation department of even a medium-sized operating 
plant may include between 3,000 and 6,000 field devices such as valves and 
transmitters. In such an environment, the instrument technician or control 
engineer responsible for a process area simply does not have the time to review 
the operation of all the field device instrumentation and control loops to detect 
which loops or devices may not be operating properly or may have some 
problem therein. In fact, because of limited manpower, the only devices usually 
scheduled for maintenance are those that have degraded to the point that they 
dramatically impact the quantity or quality of the product being produced. As a 
result, other devices or loops which need to be retained or which otherwise 
have a problem therein that could be corrected using the tools at hand are not 


corrected, leading to the overall degraded performance of the process control 
system. 

The patent application entitled "Diagnostics in a Process Control 
System," which was filed on February 22, 1999 as patent application Serial No. 
09/256,585, discloses a diagnostic tool which automatically collects 
measurements of certain parameters of blocks within a process control system 
and which then detects problems or poorly performing loops or blocks within 
this system based on the collected data to thereby ease an operator's task of 
detecting faulty or poorly performing devices and loops. However, more 
recently, multi-variable control blocks or techniques are being used to provide 
control in a process control system. Generally speaking, multi-variable control 
blocks, which may, for example, implement model predictive control, neural 
network, adaptive tuning, multi-variable fuzzy logic, RTO optimizing, or 
blending techniques, simultaneously produce one or more process control 
outputs using two or more process inputs provided to the control block. Similar 
to single-loop control strategies, it is desirable to provide a diagnostic tool that 
can detect and possibly correct poorly performing or problematic loops which 
use such multi-variable control blocks. 

According to a first aspect of the present invention we provide a 
diagnostic tool for use in a process control system having a multiplicity of 
function blocks wherein one of the multiplicity of function blocks is a multi- 
variable function block, the diagnostic tool comprising: 

a data collection unit configured to communicate with each of the 
multiplicity of function blocks including the multi-variable function block to 
receive at intervals, which may be on a regular basis, during operation of the 
process control system, data pertaining to a function block operating parameter 
for each of the multiplicity of function blocks; 
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a data analyzer that determines a value for the function block operating 
parameter for each of a number of times during operation of the process control 
system based on the received function block operating parameter data; 

a detector that detects a problem within the process control system based 
on the determined values of the function block operating parameter; and 

an output generator that creates a report indicating the detected problem. 

According to a second aspect of the present invention we provide a 
diagnostic tool for use in a process control system that includes a processor and 
that uses a multiplicity of function blocks including at least one multi-variable 
function block to control a process, the diagnostic tool comprising: 

a computer readable memory; and 

a routine stored on the computer readable memory and adapted to be 
implemented on the processor, wherein the routine; 

collects at intervals, which may be on a regular basis, data pertaining to a 
function block operating parameter for each of the multiplicity of function 
blocks including the multi-variable function block during operation of the 
process; 

determines a value for the function block operating parameter for each 
of a number of times during the operation of the process control system based 
on the collected function block operating parameter data; 

detects a problem within the process control system based on the 
determined values of the function block operating parameter; and produces a 
report that lists the detected problem. 

A diagnostic tool according to either aspect of the present invention for 
use in process control system that utilizes multi-variable control techniques or 
blocks automatically collects and stores data pertaining to one or more of the 
different multi-variable blocks (devices or loops) within the system, processes 
that data to determine which of these blocks, devices, or loops have problems 
that may result in the reduced performance of the process control system, and 
then may suggest the use of other, more specific diagnostic tools to further 


analyze and correct the problem. The diagnostic tool may detect problems or 
identify poorly performing devices or loops using variability indications, mode 
indications, status indications or limit indications associated with each of the 
input or output variables used by or created by the multi-variable function 
blocks or devices within a process control system. The variability indication is 
preferably determined or partially determined by each function block within the 
process control system to provide a statistical measurement of the deviation of 
a parameter associated with the device or function block from a set point or 
other value associated with the device or function block. The mode indication 
identifies the mode in which a function block or device is operating, e.g., a 
normal mode or a non-normal mode, to indicate if the device or function block 
is operating in its designed mode. The status indication identifies the quality of 
a signal associated with the function block or device at any given time. The 
limit indication may identify if a function block signal is limited in nature. 

The diagnostic tool may determine which function blocks, devices or 
loops have problems associated therewith based on the instantaneous values or 
on a compilation of the historical values of one or more of the variability 
indication, the mode indication, the status indication, the limit indication or 
other data associated with each function block or device. Thereafter, the 
diagnostic tool may report detected problems to an operator via a display screen 
and/or may generate written reports (such as printed reports) or electronic 
reports sent, for example, over the Internet (e.g., through E-mail) to concerned 
persons. 

Upon detecting problems within one or more process control devices 01 
loops, the diagnostic tool may suggest the proper tool(s) to be used to further 
pinpoint the problem and/or to correct the detected problem. If requested to do 
so, the diagnostic tool executes these further tools on a host workstation to 
enable an operator to perform further diagnostic functions. In cases where the 
diagnostic tool requires the use of fuuhci data intensive Looib io diagnose ui 
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pinpoint a specific problem (such as an expert system or a correlation analysis 
tool), the diagnostic tool may automatically configure the host system to collect 
the data needed to run that further tool. 

In this manner, the diagnostic tool identifies the function blocks, 
devices, loops, etc. which need attention without requiring an operator to 
review massive amounts of data pertaining to numerous devices and loops 
within a process control system. This saves time on the part of the operator and 
does not require the operator to have a great deal of expertise in detecting 
problem loops and devices, especially with respect to multi-variable function 
blocks or control strategies which are very complex. Also T upon detecting a 
problem, the diagnostic tool may recommend the use of further tools to 
pinpoint and/or correct the problem, which enables the operator to correct 
problems without having to guess as to which tool is the most appropriate in 
any given situation. Besides saving time, this function reduces the burden on 
the operator and helps to assure that the proper diagnostic tools are used in each 
circumstance. 

The invention will now be described by way of example only with 
reference to the accompanying drawings, wherein; 

Fig. 1 is a block diagram of a process control system in which a multi- 
variable function block diagnostic tool can be used; 

Fig. 2 is a block diagram of a process control system of Fig. 1 
illustrating the configuration of two process control loops run in conjunction 
with a diagnostic tool; 

Fig. 3 is a block diagram of a function block having a variability 
indication generator therein; 

Fig. 4 is a block diagram of a routine implemented by a diagnostic tool 
to perform diagnostics in the process control system of Figs. 1 and 2; 

Fig. 5 is a first example screen display generated by the diagnostic tool 
used in the process control system of Figs, i and 2, 


Fig. 6 is a second example screen display generated by the diagnostic 
tool used in the process control system of Figs. 1 and 2; 

Fig. 7 is a third example screen display generated by the diagnostic tool 
used in the process control system of Figs. 1 and 2; 

Fig. 8 is a block diagram of the controller and operator workstation of 
Figures 1 and 2, illustrating trending communications associated with a 
diagnostic tool; 

Fig. 9 is a block diagram of a process control loop using a multi-variable 
control block; 

Fig. 10 is a set of diagrams illustrating example multi-variable function 
blocks; and 

Fig. 11 is a block diagram of a multi-variable function block having a 
variability indication generator, a mode indication generator and a status 
indication generator therein. 

Referring now to Fig. 1, a process control system 10 includes a process 
controller 12 connected to a host workstation or computer 13 (which may be 
any type of personal computer or workstation) having a display screen 14 and 
connected to field devices 15-22 via input/output (I/O) cards 26 and 28. The 
controller 12, which may be by way of example, the Delta V™ controller sold 
by Fisher-Rosemount Systems, Inc., is communicatively connected to the host 
computer 13 via, for example, an ethemet connection and is communicatively 
connected to the field devices 15-22 using any desired hardware and software 
associated with, for example, standard 4-20 ma devices and/or any smart 
communication protocol such as the Fieldbus protocol. The controller 12 
implements or oversees a process control routine stored therein or otherwise 
associated therewith and communicates with the devices 15-22 and the host 
computer 13 to control a process in any desired manner. 

The field devices 15-22 may be any types of devices, such as sensors, 
valves, transmitters, positioners, etc. while the I/O cards 26 and 28 may be any 
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types of I/O devices conforming to any desired communication or controller 
protocol. In the embodiment illustrated in Fig. 1, the field devices 15-18 are 
standard 4-20 ma devices that communicate over analog lines to the I/O card 26 
while the field devices 19-22 are smart devices, such as Fieldbus field devices, 
that communicate over a digital bus to the I/O card 28 using Fieldbus protocol 
communications. Generally speaking, the Fieldbus protocol is an all-digital, 
serial, two-way communication protocol that provides a standardized physical 
interface to a two-wire loop or bus that interconnects field devices. The 
Fieldbus protocol provides, in effect, a local area network for field devices 
within a process, which enables these field devices to perform process control 
functions (using Fieldbus function blocks) at locations distributed throughout a 
process facility and to communicate with one another before and after the 
performance of these process control functions to implement an overall control 
strategy. It will be understood that, while the Fieldbus protocol is a relatively 
new all-digital communication protocol developed for use in process control 
networks, this protocol is known in the ait and is described in detail in 
numerous articles, brochures and specifications published, distributed, and 
available from, among others, the Fieldbus Foundation, a not-for-profit 
organization headquartered in Austin, Texas. As a result, the details of the 
Fieldbus communication protocol will not be described in detail herein. Of 
course, the field devices 15-22 could conform to any other desired standard(s) 
or protocols besides the Fieldbus protocol, including any standards or 
protocols developed in iJiC future. 

The controller 12 is configured to implement a control strategy using 
what are commonly referred to as function blocks, wherein each function block 
is a part (e.g., a subroutine) of an overall control routine and operates in 
conjunction with other function blocks (via communications called links) to 
implement process control loops within the process control system 10. Function 
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transmitter, a sensor or other process parameter measurement device, a control 
function, such as that associated with a control routine that performs PID, fuzzy 
logic, model predictive control, neural network, etc. control, or an output 
function which controls the operation of some device, such as a valve, to 
perform some physical function within the process control system 10. Of 
course hybrid and other types of function blocks exist. Function blocks may be 
stored in and executed by the controller 12, which is typically the case when 
these function blocks are used for, or are associated with standard 4-20 ma 
devices and some types of smart field devices, or may be stored in and 
implemented by the field devices themselves, which is the case with Fieldbus 
devices. While the description of the control system is provided herein using 
function block control strategy, the control strategy could also be implemented 
or designed using other conventions, such as sequential function charts, ladder 
logic or any other programming strategy implemented in any desired 
programming language or paradigm. 

The left side of the controller 12 illustrated in Fig. 2 includes a 
schematic representation of interconnected function blocks 30, 32, and 34 
making up an example single-input/single-output process control loop 36 
configured to use the standard 4-20 ma devices 17 and 18. Because the function 
blocks 30, 32 and 34 are related to the operation of 4-20 ma devices, these 
function blocks are stored in and executed by the controller 12. In a preferred 
embodiment, in which a DeltaV controller is used, the function blocks 30 7 32 
and 34 are configured to be similar to, that is, to use the same or similar 
protocol, as Fieldbus function blocks. However, this convention is not 
necessary as other function block or programming configurations could be used 
instead. As illustrated in Fig. 2, the function block 30 is an analog input (Al) 
function block that provides a measurement made by, for example, the 
transmitter (sensor) device 17, to the function block 32. The function block 32 
is a PID function block that performs calculations using any desired FID 
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strategy and delivers a control signal via a link to the function block 34, which 
is preferably an analog output (AO) function block. The AO function block 34 
communicates with, for example, the valve device 18 to cause the valve 18 to 
open or close according to the control signal from the PID function block 32. 
The AO function block 34 also delivers a feedback signal, which may be 
indicative of the position of the valve 18, to the PID function block 32, which 
uses this feedback signal to generate the control signal. The controller 12 
includes a device interface 38 (which may be implemented in the controller 12 
or in the I/O device 26 of Figure 1) to communicate with the devices 15-18 to 
obtain measurements made thereby and to deliver control signals thereto 
according to the control loop 36 or other control loops. The device interface 38 
systematically receives signals from the devices 15-18 and delivers these 
signals to the proper function block within the controller 12 associated with the 
sending device. Likewise, the device interface 38 systematically delivers 
control signals from function blocks within the controller 12 to the proper field 
device 15-18. 

The right side of the controller 12 in Fig, 2 illustrates a sample single- 
input/single-output control loop 40 implemented using Fieldbus function blocks 
42, 44 and 46 located down within the Fieldbus field devices 19 and 22. In this 
instance, the actual function blocks 42, 44, and 46 are stored in and executed 
by the field devices 19 and 22 and communicate their associated attributes to 
shadow function blocks 42S, 44S and 46S (illustrated as dotted-line boxes) 
within the controller 12. The shadow function blocks 42S, 44S and 46S are set 
up according to the function block configuration used by the controller 12 but 
mirror the state of the actual function blocks 42,44 and 46, respectively, so that 
it appears to the controller 12 that the actual functions associated with the 
function blocks 42, 44 and 46 are being executed by the controller 12. The use 
of shadow function blocks within the controller 12 enable the controller 12 to 
implement a control strategy using function blocks stored in and executed 
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within the controller 12 as well as within field devices. Of course, the 
controller 12 can implement control loops having both standard function blocks 
(like function blocks 30, 32 and 34) and shadow function blocks therein. For 
example, the PID shadow function block 44S, associated with the actual 
function block 44 in the valve positioner 22, could be linked to the AI function 
block 30 and the AO function block 34 to form a process control loop. The 
creation and implementation of shadow function blocks is not the subject of the 
present invention and is described in more detail in U.S. Patent Application 
Serial No. 09/151,084 entitled "A Shadow Function Block Interface for Use in 
a Process Control Network," filed September 10, 1998, which is assigned to the 
assignee of the present invention and the disclosure which is hereby expressly 
incoiporated by reference herein. 

The controller 12 and/or the field devices connected to the controller 12 
may additionally or alternatively implement one or more 
multi-input/multiple-output control loops using multi-variable control blocks or 
programs, such as blocks which implement control or other operations based on 
model predictive control (MPC) logic, neural network control logic, adaptive 
tuning logic, fuzzy logic control logic, optimization logic, blending logic, etc. 
Fig. 9 illustrates a multi-variable control loop 140 which uses an MPC control 
block 142 to implement a three-by-three MPC control technique. As illustrated 
in Fig. 9, three AI blocks 144, 146 and 148 provide process inputs to the MPC 
block 142 which uses these inputs, as well as constrained inputs, 150 and 152 
and a set-point 153 delivered from, for example, an operator, to perform MPC 
control in any known or desired manner. The MPC block 142 produces three 
output signals which are provided to AO blocks 154, 156 and 158 which, in 
turn, control parameters within the process, such as the opening and closing of 
valves, etc. Of course, one or more of the input signals to the MPC block 142 
may be feedback or back calibration signals provided by one of the AO blocks 
154, 156 and 158. 
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The operation of MPC is known and, as such, will not be described in 
detail herein. However, as is known generally, each MPC block as well as other 
types of multi-variable blocks typically has three kinds of inputs including 
controlled parameter inputs which are the process variables or parameters that 
are to be maintained at a set point (or within a set range), constrained inputs 
which are the process variables that are constrained to a particular limit or 
range based on, for example, physical limitations associated with the process 
and which the control block must not force to-be outside of the constrained 
range or limit, and process disturbance parameter inputs, which are other 
process variables, such as process inputs that, when altered, are known to cause 
changes to the controlled parameters. 

An MPC block uses the process disturbance parameter inputs to foresee 
changes to the controlled parameters (i.e., the controlled process outputs) and 
to limit the effects of these changes before they occur. Other inputs may also be 
provided to the MPC block 142, such as feedback from a device or other 
process element being controlled which enables the MPC control block 142 to 
provide more effective control of these elements. Similarly, the outputs of the 
MPC block 142 may be connected to control any desired process variable or 
other process input including control loop inputs, device control inputs, etc. 

Of course, the MPC block 142 could be replaced with any other multi- 
variable block. Likewise, the multi-variable loop 140 may be implemented 
entirely within the controller 12, entirely within one or more smart field devices 
or partially within the controller 12 and one or more smart field devices, in a 
manner similar to that described above with respect to 
single-input/single-output control loops. 

Moreover, while the MPC control block 142 is illustrated as a 
three-by-three block, it or any other multi-variable block used could have any 
desired number of two or more inputs and/or any desired number of outputs. As 
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will be understood, the number of input and outputs to a multi-variable block 
can be the same or different. 

For the purposes of this invention, a control block can be any part or 
portion of a process control system including, for example, a routine, a block or 
a module stored on any computer readable medium. Moreover, control blocks 
or routines, which may be modules or any part of a control procedure such as a 
subroutine, parts of a subroutine (such as lines of code), etc. may be 
implemented in any desired software format, such as using ladder logic, 
sequential function charts, function block diagrams, or any other software 
programming language or design paradigm. Likewise, the control routines may 
be hard-coded into, for example, one or more EPROMs, EEPROMs, 
application specific integrated circuits (ASICs), or any other hardware or 
firmware elements. Still further, the control routines may be designed using any 
design tools, including graphical design tools or any other type of 
software/hardware/firmware programming or design tools. Thus, the controller 
12 may be configured to implement a control strategy or a control routine using 
single-input/single-output or multiple-input/multiple-output control blocks in 
any desired manner. 

The MPC block 142 of Fig. 9 has been provided as an example multi- 
variable block that could be used in a process control system. Of course other 
types of multi-variable blocks could be used as well. For example, Fig. 10 
illustrates other multi-variable blocks that accept multiple inputs to produce one 
or more outputs. In particular, as illustrated in Fig. 10, multi-variable blocks 
could include a neural network wherein multiple inputs are used to produce a 
single output, adaptive tuning wherein multiple inputs are used by a tuning 
block to produce one or more outputs, or multi-variable fuzzy logic, RTO plus 
optimization or blending, wherein multiple inputs are used to produce multiple 
outputs. Of course, any other multi-variable blocks could be used as well. 
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Referring again to Fig. 1, in one embodiment of the present invention, 
the controller 12 includes a diagnostic data collection unit 48 which may be, for 
example, a short term memoiy that collects and stores certain kinds of data 
associated with each of the function blocks (or shadow function blocks) of the 
process control system 10 for use in detecting problems with those function 
blocks, or the devices or loops associated with those function blocks. The data 
collection unit 48 may, for example, collect and store a variability indication, a 
mode indication, a status indication and/or a limit indication for each of the 
function blocks within the process control network 10. If desired, the data 
collection unit 48 may perform some processing on the collected data as 
described below. The data collection unit 48 periodically sends the collected or 
processed data to the operator workstation 13 via the ethemet connection for 
storage in a long term memoiy or historian 50 and for use by a diagnostic tool 
52 located at least partially within the operator workstation 13. The diagnostic 
tool 52, which is preferably implemented in software stored in a memory of the 
operator workstation 13 and executed by a processor 54 of the operator 
workstation 13, detects problems within the process control system 10, reports 
these problems and suggests tools for use in further analyzing and correcting 
these problems. If desired, portions of the diagnostic tool software can be 
executed within the controller 12 or even within the field devices. 

The diagnostic tool 52 systematically detects problems using one or 
more operating parameters of the function blocks or devices within the process 
control system 10 including, for example, a variability parameter, a mode 
parameter, a status parameter and a limit parameter determined by (or 
associated with) each of the function blocks or devices within the process 
control network 10. An indication of the variability parameter can be calculated 
or otherwise determined for each device or function block within the process 
control system (whether those function blocks are implemented within the 
controller 12 or down within one of the field devices 19-22) to indicate the 
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error between two parameters of the function block. These two parameters may 
be different signals associated with the function block or may be two different 
measurements of the same signal. For example, for AI function blocks, the 
variability indication may indicate the error between a statistical measure (such 
as the mean, median, etc.) of the measurement made by a sensor over a 
predetermined amount of time and the actual or instantaneous value of the 
measurement. Similarly, for an AO function block, the variability indication 
may be calculated based on the differences between an historical statistical 
state of a device over a predetermined amount of time (such as the average 
location of the valve in a valve device) and the current state of the device (such 
as the current location of the valve). For control function blocks, such as PID, 
ratio or fuzzy logic function blocks and or for any multi-variable control block, 
the variability indication may be based on a deviation of a process parameter 
input to the function block and a set point or target provided to the function 
block for that parameter. 

In one embodiment, a variability index may be determined as the 
integrated absolute error (IAE) over a particular interval, such as a ten minute 
evaluation period. In such a case, the variability index can be calculated as: 


IAE = Z 


\X(0-S\ 


(1) 


wherein: 


N 


ihe number of samples in the evaluation 
period; 


X(i) 


the value of the ith sample of the desired 
function block parameter, such as the input 
to the function block for AI blocks and 
control blocks; and 
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S = the statistical or target value of the parameter 
to which the function block parameter is 
compared, e.g., the set point (for control 
blocks), the average value of the function 
block parameter over the last evaluation 
period (for AI blocks), etc. 
If the variation between the X and S variables of equation (1) is 
Gaussian in nature, then the IAE is equal to the standard deviation times the 
square root of the product of two over pi. Of course, any other variability 
indication could be used in addition to or instead of the IAE calculation 
described above and, thus, the variability indication is not confined to that of 
equation (1). 

Preferably, each function block, and especially those located within the 
field devices 19-22, automatically calculates a variability indication over each 
evaluation period (e.g., over a predetermined amount of time or number of 
execution cycles) and, after each evaluation period, sends the calculated 
variability indication to the data collection device 48 within the controller 12 or 
to the data historian 50 within the operator workstation 13. This variation 
indication may be, for example, the variability index given above or may be 
subparts thereof which can be used to determine the variability index given 
above. If the function blocks are Fieldbus function blocks located within one of 
the field devices 19-22, then the variability indication may be sent to the 
controller 12 using asynchronous communications. 

While the final variability index for each function block could be 
completely calculated by the controller 12 or the operator workstation 13, this 
would require each function block to send data to such devices after every 
execution cycle (typically on the order of every 50-100 milliseconds), which 
would require a lot of additional communications over the buses of the process 
control network 10. To eliminate this additional communication, it is preferable 
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to design each function block to calculate a variability indication therefor and 
then send this variability indication over the communication buses once every 
evaluation period, which will typically be on the order of once every minute, 
ten minutes or more. Currently, no known standard function blocks or 
multi-variable function blocks provide this capability and, therefore, it should 
be added to the function blocks used within the process control system 10. 

In one embodiment, the calculations for a final variability index 
associated with a function block are split between the function block and the 
diagnostic tool 52. In particular, because the computation of the variability 
index takes computing resources, the most computationally consuming parts of 
these calculations are done in the workstation 13 or the controller 12. For this 
discussion, the calculations for a variability index for input and output blocks 
will be referred to simply as a variability index (VI) while the variability index 
for control function blocks will be referred to as a control index (CI). The VI 
(which is used for input blocks, output blocks and control blocks in manual 
mode) and the CI (which is used for control blocks in auto mode) can be 
calculated by the workstation 13 or the controller 12 as follows: 


VI = 1 - 


(2) 


CI = 1 


(3) 


wherein: 

Su, = minimum standard deviation expected with 

feedback control; 
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s 


- sensitivity factor used to make the 
calculations stable. 


Si q may be calculated as: 



2- 


S 


capab 


(4) 


wherein: 


* capab 


estimated capability standard deviation (standard 
deviation at process ideal operation). 


A small bias value s is added to the S capab and S lol values in equations (2) 
and (3) because it has been discovered that, if the disturbance to noise signal 
ratio (i.e., the low frequency to high frequency disturbance ratio) is too high, 
the VI and CI calculations give too high of values. Fast sampling with very 
small differences between consecutive measurements also attributes to this 
problem. The bias value s, it has been found, makes the computations stable. 
The recommended bias value s is 0.1% of the measurement range 
(approximately the measurement accuracy). It will be understood that a value 
of zero for the VI or CI calculations of equations (2) and (3) is the best case 
while a value of one is the worst case. However, these or other variability 
indices could be calculated so that a value of one (or even some other value) is 
the best case. 

For multi-variable blocks, an individual CI or VI value may be 
calculated for each controlled index, for example, each input or output to the 
multi-variable block, using the equations given above and a final CI or VI value 
for the multivariate block may be computed as some combination of the 
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individual CI or VI values. For example, the final CI value for a multi-variable 
block may be computed as: 

c h = J-t CW) (5) 

Here, L is the number of individual CI values (i.e., control indices) 
associated with the multi-variable block and CI,, is the final value for the CI 
parameter for the multi-variable block. It will be understood from equation (5) 
that the CI F value is an average or a weighted average of the control indexes for 
the individual controlled variables of the multi-variable block. However, the 
CI F value could be determined as some other statistical combination of the 
individual CI values instead. Of course, a similar approach could be taken with 
the VI value for a multi-variable block. Also, the computation of the CI F or the 
VI F values could be performed in the device in which the multi-variable 
function block exists, or in the controller 12 or the historian 13 or other 
processor device. 

If desired, a percent improvement (PI) value can be established for the 
control blocks as 100 times the CI value for the control block. It may also be 
desirable to compute the variability improvement for a particular variable 
which results from the use of advanced control for that variable. In this case, an 
advanced control improvement index (AO I) can be calculated as the ratio of 
the minimal control index (CI nim ) achieved over a certain period of time using 
non-multi-variable control (e.g., a single-input, single-output control loop) over 
the control index (CI F ) for the multi-variable block used to control that variable 
in the multi-variable control scheme. 

In the case of plant optimization, the objective of the plant may be 
specified by an objective function, in which case, the measurement of the total 
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optimum value achievable and that actually realized by the control application. 
For most control applications, the optimum performance is achieved when 
constrained process inputs are as close to the constrained limits as possible. 
Therefore, an optimality index may be defined as a percent of time in which at 
least one process input was at its constraint, or within a predefined range or 
value of a constraint. A constrained violation index may also be defined as the 
amount of time that at least one process input or output exceeds its constraints. 
For monitoring applications, such as multi-variable virtual sensors, a variability 
index can be determined from the total and capability standard deviations 
resulting from the difference between the predicted measurement value (the 
output of the virtual sensor) and the value determined based on lab tests. 

To perform the above VI, CI and PI calculations in the most efficient 
manner possible, each of the function blocks in, for example, the DeltaV 
environment or the Fieldbus environment may calculate the S capa b and S tot 
values for each of the appropriate inputs or outputs of the block as variability 
indications and make these values visible to the controller 12, which can then 
calculate the VI and CI values using equations (2), (3) and (5) or can provide 
the S capab and Sic values to the diagnostic tool 52 in the workstation 13 which 
can calculate the VI and CI values. The intermediate calculations needed to 
determine the S capab and S, l>t values will be performed each execution of the 
function block and the S capab and S lot values will be updated once every N 
executions of the function block (i.e., once every evaluation period). In one 
implementation, the S capah and S tot values may be updated after 100 executions 
of the function block. 

The total standard deviation S lo , can be calculated in the function block 
using the so-called moving time window computation as follows: 


S w = \25MAE 


(6) 
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wherein MAE is the mean absolute error calculated as: 


MAE=jjt\y(0-y s ,\ (7) 

and wherein: 


N = the number of executions in an evaluation 

period; 


y(t) = the value of the t'th instantaneous sample 

of the desired function block parameter, such 
as the input to the function block; and 

y s t = the statistical or target value of the parameter 

to which the function block parameter is 
compared, e.g., the average or mean value of 
the function block parameter over the last 
evaluation period. 

Generally speaking, the process value (PV) of the function block will be 
used in the I/O blocks to calculate y sl . In control blocks, either the working 
setpoint or the PV can be used as y st , depending on the block mode. 


The capability standard deviation, S oapiib , can be calculated as follows: 


MR 
1.128 


(8) 


( 
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wherein MR is the average moving range, which may be calculated as: 


A^ = 77^SICV(0-J</-1))| (9) 


To reduce computations, only the summing component associated with 
the MAE and MR will be done during each execution cycle of the function 
block. The division of the sum by N or N- 1 can be done as pail of the S tol and 
Scapab calculations once eveiy N executions (i.e., once every evaluation period). 
From the above formulas it is evident that: 


S [ol ^ 123* * Error ^ (10) 


1 

; * Delta , 
A — 1 

^ca/hih ~ | pg (11) 


wherein the Error abs and the Deltas are the summations in equations (7) and 
(9) respectively and are calculated on an ongoing basis during each execution 
cycle of the function block. Of course, the quality of the input to the function 
block used in these calculations is important and, thus, it is desirable to only 
use data that has good status and data that is not limited. When using Fieldbus 
or DeltaV function blocks, the mode variable takes the status of the PV, set 
point and BackCalibration variables into account, and so the mode variable can 
be used to assure proper calculations for the variability index. For example, in 
the OOS (out of service) mode, the S tot and S capill) variables are not determined 
but arc, instead, set to the best case value (e.g., zero) iu pievcm the detection of 
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an error. On warm starts, if the mode changes from OOS to any other mode, the 
S tot and Scapab variables can be set to zero (a best case value), the scan counter 
can be reset and the Error abs and Data abs variables of equations (10) and (11) 
can be set to zero. Also, the previous values of y and y st should be reset. 

Fig. 3 illustrates a function block 55 having an input 56, an output 57 
and a variability indication generator 58 connected to the input 56. If desired 
the variability indication generator 58 may be additionally or alternatively 
connected to the output 57 and/or to other parts of the function block 55 to 
receive other function block parameters or signals (these connections being 
illustrated by dotted lines in Fig. 3). If the function block 55 is, for example, a 
control function block, the variability index calculator 58 receives the input 56 
(which may be the process value that is being controlled by the loop in which 
the control block 55 operates) and compares that input to a set point previously 
supplied to the function block 55. The variability indication generator 58 may 
determine the variability index according to equation (1) and send that index to 
a communicator 59 which sends the variability indication to the controller 12 
every evaluation period (every N samples). However, as described above, the 
variability indication generator 58 may determine the S to , and S capab values in 
the manner described above and send these values to the controller 12 or 
workstation 13, which can determine the VI and/or CI values therefrom. If the 
function block 55 is a function block being executed within the controller 12, 
the controller 12 could include a separate routine to determine the variability 
indication for each function block, as no bus communications would need to 
take place after each sample interval. The communicator 59 can be any 
standard communication unit associated with a function block or a 
communication protocol. 

Of course, a variability index generator may also be provided in a 
multivariable block, as is illustrated in more detail in Fig. 1 1. In particular, Fig. 
ii illustrates a multi-variable block 160 having three control inputs and two 
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outputs. Of course, if desired, more or less inputs, including constraint and set 
point inputs or more or less outputs could be used as well. The block 160 
includes a variability index generator 162 which is connected to each of the 
inputs and which may be connected to one or more of the outputs and computes 
a CI (or VI) for each of the inputs in any of the maimers discussed above. Thus, 
the variability index generator 162 may compute the S tot and S capab values for 
each input and/or output and send these values to the controller 12 or may 
compute initial VI or CI and send these values to the controller 12 or, 
alternatively, may compute the final VI F or CI,, values using, for example, 
equation (5), and send these values to the controller 12. As is the case with the 
block of Fig. 3, the variability index generator 162 is coupled to a 
communication unit 164 which communicates the variability index(es) for the 
block 160 to the data collection unit 48 of Fig. 2. 

A second function block operating parameter that may be used to 
determine problems within the process control system is an indication of the 
mode in which each of the function blocks (or loops or devices) is operating. In 
the case of Fieldbus function blocks, as well as some other known function 
blocks, each function block has a mode parameter that is available to the 
controller 12 to indicate the mode in which the function block is operating. 
From this mode indication, a data analyzer within the diagnostic tool 52 can 
determine a value of the mode parameter to indicate if the function block (and 
thereby the loop, module or device) is operating in its desired or designed mode 
or, alternatively, if something has occurred to cause the function block (device 
or loop) to operate in a different, less preferable mode. Fieldbus function 
blocks operate in one of a number of modes. 

For example, AI function blocks operate in an out-of-service mode 
(wherein an operator may have put the device out-of-service to perform 
maintenance), a manual mode in which some signal, such as an output of the 
function block, is being set manually instead oi based on the designed 
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operation of the function block, and an automatic mode, in which the function 
block is operating in a normal manner, i.e., the way in which it was designed to 
operate. Fieldbus control blocks can also have one or more cascade modes 
wherein the mode is controlled by other function blocks or by an operator. 
Typically, Fieldbus function blocks have three mode variables associated 
therewith at any given time including a target mode, which is the mode in 
which the operator has set the block to operate (which can be other than the 
normal or automatic mode), an actual mode, which is the mode in which the 
control block is actually operating at any given time, and a normal mode, which 
is the mode in which the function block was designed to operate and is 
associated with the normal operation of the function block. Of course, these or 
other mode indications may be used as desired. 

In the case of multi-variable blocks, each of the inputs or outputs can 
have a separate mode associated therewith. As illustrated in Fig. 11, a mode 
indication generator 166 may detect the mode of the inputs and outputs of the 
block and compare these mode indications to the normal mode for each of the 
inputs and outputs to determine if the block 160 is operating in an abnormal or 
non-designed mode. The mode block 166 may determine or set the overall 
mode indication of the multi-variable block 160 based on some combination of 
the individual mode indications. For example, the overall mode indication for 
the multi-variable block 160 may be set to one to indicate that the block 166 is 
operating outside of the designated mode when any of the mode indications for 
any of the individual inputs or outputs is other than the designed mode. If the 
block 160 is a Fieldbus function block, it will have a mode attribute which can 
be used to determine if the block is operating in the designed or normal mode. 
If the block 160 is not a Fieldbus function block, the mode indication generator 
166 can be designed to calculate or determine an actual mode attribute in a way 
which is similar to Fieldbus function blocks and to then compare this calculated 
actuai mode attribute to a designated normal mode attribute (provided by a 
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designer or user) to determine if the block 160 is operating in an incorrect 
mode. 

The mode indication(s) may be periodically provided to the controller 12 
and/or to the operator workstation 13. If the function block is within the 
controller 12, the mode indication for each function block may be provided to 
the data collection unit 48 at any desired time or interval. For Fieldbus function 
blocks or other function blocks within the field devices, the controller 12 may 
periodically request the mode parameters for each function block using a 
ViewList request (in the Fieldbus protocol). If desired, the data collection unit 
48 within the controller 12 may store the mode at each sampling period or 
evaluation period and provide the stored data to the data historian 50. 
Thereafter, the diagnostic tool 52 may determine mode values indicating when 
or how long the function block spent in the different modes or in a normal 
mode (or a non-normal mode) or indicating what percent of a specific time 
period the function block was in a normal mode (or a non normal mode). 
Alternatively, the data collection unit 48 or some other specifically designed 
unit within the controller 12 could detect when each function block is out of its 
normal mode by, for example, comparing the function block's normal mode 
with its actual mode at any given time. In this case, the data collection unit 48 
could communicate the mode of any function block by indicating when changes 
in the mode took place or are detected, which reduces the amount of 
communication needed between the controller 12 and the operator workstation 
13. 

A status parameter is another function block operating parameter that 
may be used to detect problems within process control devices and loops. A 
status indication provided by each function block may define or identify the 
status of the primary value (PV) associated with the function block or device. 
In addition or alternatively, one or more of the inputs and outputs of a function 
block may have a status indication associated therewith. Fieldbus function 
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blocks have a status parameter associated therewith which can take on the form 
of "good", "bad" or "uncertain" to indicate the status of the function block PV, 
inputs and/or outputs. A status indication may also identify or include a limit 
indication, such as the limits associated with the PV or other function block 
parameter. Thus, for example, the limit indication may indicate whether the PV 
of the function block is high or low limited. Again, the diagnostic tool 52 may 
determine status values or limit values indicating when, how long or what 
percent of a specific time period the status of the function block was a normal 
status (or a non-normal status), and when, how long or what percent of a 
specific time period a function block variable was at one or more limits (or not 
at the one or more limits), or was a bad status or a questionable status. 

In the case of multi-variable blocks, each of the inputs or outputs can 
have a separate status associated therewith. As illustrated in Fig. 11, a status 
indication generator 168 may detect the status of all of the inputs of the block 
160 that directly impact the control or calculation performed by the block 160. 
The status indication generator 168 may determine an overall status value for 
the block 160 based on some combination of the individual status indications. 
For example, the status indication for the multi-variable block 160 may be set 
to bad, uncertain or limited if any one of the monitored signals has a status that 
is bad, uncertain or limited. If the block 160 is a Fieldbus function block, it will 
support a status attribute for each of the primary variables, which can be used 
to support the status attribute. If the block 160 is not a Fieldbus function block, 
the status indication generator 168 can be designed to calculate or determine an 
actual status for each of the primary inputs or outputs in a way which is similar 
to Fieldbus function blocks and to then use these status indications to determine 
an overall status indication for the block 160. The status indication generator 
168 may treat limit indications for each of the input or outputs of a 
multi-variable block in a similar manner. 
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Similar to the mode indication, the status indication and the limit 
indication may be sent by each function block to the controller 12 periodically 
or on request (using, for example, the ViewList command in the Fieldbus 
protocol) and changes therein may determined by the controller 12 and sent to 
the operator workstation 13. Alternatively, the status and limit indications may 
be sent to the operator workstation 13 without being processed. If desired, the 
function blocks may be set up to communicate mode, status and/or limit 
indications only when changes therein actually take place, which further 
reduces the amount of communications between the controller 12 and the 
function blocks within field devices. However, when using this communication 
scheme, the current state of all the required parameters is needed to establish a 
base against which to compare the changes when the diagnostic tool 52 is first 
placed on line. This current state may be measured or collected by having the 
controller 12 periodically report parameter values (even though they have not 
changed) or by having the diagnostic tool 52 cause the controller 12 to report 
parameters defined for exception reporting. Based on the status of each of the 
function blocks, the diagnostic tool 52 can quickly identify measurements 
which are bad, and need attention (uncertain status) or which have been 
incorrectly calibrated because they have a measurement or PV that is limited. 
Of course, the status and limit indications may take on one of any different 
number and types of values, depending on the type of system in which they are 
being used. 

Furthermore, a status indication may be used for any different variables 
(other than the PV3 of a function block, device or loop. For example, in a 
control loop having feedback control, the status of the feedback variable may 
be used to detect problems within function blocks and loops. The status of this 
feedback variable (e.g., the back calibration or BackCal variable for control or 
actuator function blocks in the Fieldbus protocol), or any other variable, can be 
examined by the diagnostic tool 52 to detect when a function block has an 
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output that is limited by, for example, a downstream function block or other 
downstream condition. 

Similar to the mode indication, the controller 12 may detect and store 
actual status values or may store changes in the status values as the status 
indication. 

Other data associated with a process control function block, device or 
loop may be used to detect problems as well. For example, the operator 
workstation 13 (or the controller 12) may receive, store and review events and 
alarms generated by the devices or function blocks within the process control 
network 10. In, for example, the Fieldbus environment, function blocks support 
a block error parameter that reports abnormal processing conditions detected by 
a transducer or a function block. Fieldbus devices reflect any problem that is 
detected by the device or function block using one of 16 defined bits in a block 
error bitstream sent to the controller 12. Fieldbus devices report the first 
detected problem to the controller 12 as an event or alarm and these events or 
alarms can be forwarded by the controller 12 to an operator workstation 14 
event journal. In one embodiment, the diagnostic tool 52 analyzes or reviews 
the 6th bit of the block error parameter (in the Fieldbus protocol) to detect 
when a device needs maintenance soon and, thus, when a condition exists that 
must be addressed but which is not currently limiting device operation. 
Similarly, the diagnostic tool 52 analyzes the 13th bit of the block error 
parameter (in the Fieldbus protocol) to determine when correct device 
operation is not possible because of a condition detected by the device and, 
thus, immediate action is required. Of course, other events, alarms, other bits 
within the block error parameter or other types of error indications may be used 
by the diagnostic tool 52 to detect problems associated with the operation of the 
process control network 10, and such other events, alarms etc. may be 
associated with the Fieldbus protocol or any other desired device or controller 
protocol. 
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In some instances, function blocks may have parameters, such as mode 
or status parameters that are set to other than normal or good for reasons 
unrelated to the correct operation of the process or loop in which these function 
blocks operate. 

For example, in batch processes, when a batch is not being run, the 
modes of the function blocks used within that process are set to non-normal 
values. However, it would be undesirable to detect these non-normal mode (or 
status) indications and identify problems with the system based thereon because 
the batch process is designed to have down times. It is preferable, therefore, to 
provide each function block (or the module or loop in which it is run) with an 
application state parameter indicating if the function block (or module) is 
purposely in a non-normal mode, or has a bad status. In other words, the 
application state parameter will indicate when alarming or problem detection 
for the function block should be prevented. For function blocks used in batch 
processes, for example, the application state parameter will be set to one value 
to indicate when the function blocks are operating to perform a batch run 
application and will be set to another value to indicate when the function blocks 
are purposely not being used to perform a normal function within a batch run 
application and so no detection of problems should be based on the operations 
of these function blocks at these times. Such an application state parameter is 
illustrated in Figs. 3 and 11 to be communicated tc the controller 12 via the 
communicators 59 and 164. The controller 12 and/or operator workstation 13 
may detect the application state parameter for each function block and ignore 
data (such as variability, mode, status and limit data) associated with function 
blocks that are in the second category, e.g., that are purposely set to non-normal 
or bad states, in order to prevent false alarms. Of course, there are other reasons 
that the application state parameter may be set to prevent detection of problems 
besides the down time associated with batch processes. 

The diagnostic tool 52 is preferably implemented in software within the 
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operator workstation 14 and, if necessary, some parts may be implemented in 
the controller 12 and even down within the field devices, such as the field 
devices 19- 22. Fig. 4 illustrates a block diagram of a software routine 60 that 
may be executed in the operator workstation 14 to detect and help correct 
problem function blocks, devices, loops or other entities within the process 
control network 10. Generally speaking, the software routine 60 collects data 
pertaining to each of the function blocks within a process, such as variability 
indication, mode indications, status indications, limit indications, alarm or 
event information, etc., on an ongoing basis as the process is running and 
detects the existence of problem measurements, calculations, control loops, etc. 
based on the collected data. The software routine 60 may send a report or 
create a display listing each detected problem and its economic impact on plant 
operation when configured or requested to do so. When viewing a display of 
the detected problem loops on, for example, the display 14 of the operator 
workstation 13, an operator can select a particular problem for review or 
correction. The software routine 60 then suggests and may automatically 
implement other diagnostic tools to further pinpoint the problem or to correct 
the problem. In this manner, the diagnostic tool 52 processes data generated by 
the function blocks or devices of a process control system, automatically 
recognizes problems based on the data and then suggests and executes other 
diagnostic tools to further pinpoint the cause of the problem and to correct the 
problem. This saves the operator enormous amounts of time and effort in 
detecting and collecting problems within a process control system and also 
helps to assure that the appropriate diagnostic tools (which may not be totally 
familiar to the operator) are used to correct the problem. 

A block 62 of the routine 60 receives and stores the variability, mode, 
status, limit, alarm, event and other data used to detect problems within 
devices, blocks and loops of the process control system 10 on an ongoing basis, 
i.e., wlicncvci ihc pioccbb is i mining. Preferably, this daia is stored in the data 
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historian 50 within the operator workstation 13, Alternatively, however, this 
data could be stored in any other desired memory, such an in a memory 
associated with the controller 12. Likewise, this data may be sent to the 
operator workstation 13 in any format and may be sent as compressed data, if 
so desired. 

A block 63 detects or determines when an analysis of the data is to be 
performed because, for example, a periodic report is to be generated or because 
a user is requesting such an analysis. If no analysis is to be performed, the 
block 62 simply continues to collect data and may process that data to 
determine values for the function block operating parameters. If an analysis is 
to be performed, a block 64 analyzes the stored data or stored parameter values 
to determine which function blocks, devices or loops may be having problems. 
Generally speaking, the data may be analyzed based on the current or 
instantaneous values of the function block operating parameters, or may be 
analyzed on an historical basis to determine which function blocks, devices or 
loops are having problems over a specific period of time. The historical 
analysis helps to detect problems that are long term in nature based on the 
performance over a specified period of time. To detect a problem, the block 64 
may, if necessaiy, calculate a variability index from the variability indications 
supplied by the function blocks and then compare the variability index to a 
specific range or limit (which may be set by the operator) to see if either the 
instantaneous value of, or some statistical measure of the historical value (such 
as me average or median value) of the variability index is outside of the range 
or above or below the specified limit for a function block. If so, a problem may 
exist and the function block, device or loop associated with the out-of-range 
variability index is listed as having a problem to be corrected. 

Likewise, the block 64 may compare the actual mode of a function block 
or device with the normal mode of that function block or device to see if they 
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As indicated above, the controller 12 may perform this function and 
send indications of the result, or of mismatches to the historian 50. If desired, 
however, the operator workstation 13 may perform these comparisons directly. 
Using the historical data, the block 64 may determine loop utilization, i.e., the 
percent of time that the loop (or function block) operated in the designed 
(normal) mode. In the instantaneous analysis, the function block, loop or device 
may be considered to have a problem when it is currently not operating in the 
designed or normal mode. 

Similarly, the block 64 may analyze the status and limit indication(s) of 
each function block to determine when the status is bad or uncertain or 
otherwise not a designed or normal status or when a function block signal is at 
a limit. A historical analysis may calculate or determine if a particular function 
block has a status indication that is bad or uncertain for a predetermined 
percentage of a specified amount of time, may determine which PVs or other 
variables reached a limit or stayed at a limit for a predetermined percentage of a 
specified amount of time, or may analyze the status indication or limit 
indication in any other manner to determine if a problem exists within the 
function block or device or loop in which a function block is located. Likewise, 
the block 64 may determine, in an instantaneous evaluation, which function 
blocks, devices or loops have status values that are currently not in the designed 
or normal state and/or which signals or variables have reached a limit (i.e., are 
value limited). The block 64 may review the alarm and event notifications to 
see if any devices need maintenance, either now or in the future. The blocks 
which exceed the variability or control index limits and the blocks which have 
an active bad, limited, or mode condition will be identified and temporarily 
saved. This summary information can support the creation of "current" 
summary display. The instantaneous values and conditions can be integrated by 
the diagnostic tool 52 on, for example, an hour, shift and daily basis to obtain 
the average value of variability index and the percent improvement and the 
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percent time the bad status, limited signal or non-normal mode condition 
existed. Of course, the block 64 may perform other types of processing on the 
variability, mode, status, limit, event, alarm and/or any other desired data to 
detect problems. Furthermore, the block 64 may run the analysis using different 
limits, ranges, historical times, etc., all of which may be set by a user or an 
operator. 

For function blocks used in, for example, batch mode processes, data 
associated with times when a function block intentionally was not operating is 
discarded or not used in the analysis based on the application state parameter 
for the function block. 

After the block 64 has detected the problems within the process control 
network, a block 66 determines if any written or electronic reports should be 
generated because, for example, periodic reports have been requested by a user. 
If so, a block 68 creates a report listing the problem function blocks, devices, 
loops, etc. and their economic effect on the process control system. Such an 
economic impact may be determined by having an operator or other user 
specify the dollar amount associated with each percentage point of reduced 
operation of the process or a loop in the process. Then, when a loop is found to 
have a problem, the actual performance of the process loop may be compared 
to a known optimum performance value to determine the percentage difference. 
This percentage difference is then multiplied by the specified dollar amount to 
percentage point ratio to determine the economic impact in terms of dollars. 
The report may be printed out on a printing device, displayed on a computer 
screen (such as the display 14) or other electronic display, sent to a user via 
E-mail, the Internet or any other local area or wide area network, or may be 
delivered to a user in any other desired manner. If desired, the diagnostic tool 
52 may be configured to automatically notify a plant maintenance system 
whenever a problem loop is detected and this notification can be sent to the 
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maintenance system as an event using the event/alarm capability of the known 
OPC interface. 

A block 70 determines if an operator has requested an analysis to be 
performed at the workstation 13 and, if so, a block 72 enters a display or dialog 
routine that enables a user to find out different information related to the 
problem or to select different parameters for performing the analysis. In one 
embodiment, an operator or other person that uses the diagnostic tool 52 is 
presented with a dialog when he or she logs onto the workstation 13. The 
dialog summarizes the conditions that need to be addressed in the system 
without identifying the loops that are the source of the problem. The dialog 
may convey the information in a graphical format such as on screen display 80 
as shown in Fig. 5. The screen display 80 summarizes the percent of total input, 
output or control function blocks in the process or plant that currently violate 
the default limits set for utilization (mode), limited signals, bad status or high 
variability. Because multiple conditions may exist in a single block, the total 
could potentially exceed 100%. If the total exceeds 100 percent, then the 
percent for each category can be scaled so that the total equals 100 percent. 
Modules that have input, output, or control blocks that violate the preset limits 
are summarized in a tabular list 82. In Fig. 5, module FIC 101 has one or more 
function blocks operating in undesigned modes and one or more function 
blocks with high variability, while the module LIC345 has one or more 
function blocks with bad status. 

More information about the nature of the problems, such as the iimits 
associated with the function blocks, can be shown graphically by, for example, 
clicking on a module name within the list 82. Furthermore, by selecting a filter 
button 84 on the screen of Fig. 5, the user may be presented with a dialog 
allowing the user to select a summary time frame, the types of blocks to be 
included in the summary and the limit for each categoiy or block. Such a dialog 
screen 86 is illustrated in Fig. 6, where the iimits tor the mode, limited, and bad 
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status of input blocks are set at 99 percent utilization and where the limit for 
the variability index for input blocks is set at 1.3. In this case, the percent 
utilization of a block is determined as the percent of a specific time period in 
which the mode or status is normal and a function block signal was not limited. 
However, the limits could also be set as the percent of time that the mode or 
status was non-normal or a function block variable was at a limit, in which case 
the limits should be set closer to zero. Of course, by choosing all of the loop 
selections within the screen 86, all modules that include an input, output or 
control block will be included in the summary. 

A Timeframe box 88 of the screen 86 can be manipulated by changing 
the setting therein to alter the historical time frame for which the analysis is 
performed. 

For example, by choosing a "Now" selection within the Timeframe box 
88, the instantaneous or current value of the block parameters are used to 
determine if each module will illustrated as a problem module in the summary 
list 82. While any time frame may be specified, some example time frames that 
can be used in filtering are the Current Hour or Last Hour, Current Shift or Last 
Shift, Current Day or Last Day, etc. For these time frames, a module is 
included in the summaiy list only when a detected condition is present for a 
significant portion (i.e., a predetermined portion) of the selected time frame as 
defined by the limit condition. 

If desired, the user may change the limit values used for variability 
index, either per block or on a global basis. To facilitate setting variability 
limits, the user may select the desired limit to be changed and then may be 
provided with a choice of either editing that limit for a particular block or of 
setting that limit for all of the blocks simultaneously. When the user wants to 
set the variability limit for all of the blocks together, the user is presented with 
a dialog box that allows the variability limit to be set to the current value of a 
variability plus a specified bias provided by the user. 
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Of course, the limits for variability, mode, status and limited variables 
may be applied to all of the function blocks within a module, an area, a system, 
or any other logical unit and may all be changed in a similar manner. Default 
limits may be initially provided for a configuration as 1.3 for variability index 
and 99% utilization for mode, limited and status indications. Of course, these 
default values may be changed from the module summary display as described 
above. 

By selecting a module name within the summary 82 of Fig. 5, the user 
can be provided a dialog screen having further details related to that module. 
Such a dialog screen 90 is illustrated in Fig. 7, for the module FIC101 using the 
Last Shift time frame. The screen 90 illustrates the performance of a PID1 
block and an AI block within the FIC101 module. The information provided in 
the screen 90 allows the user to easily identify the particular measurement, 
actuator, or control block that caused the module to be included in the summary 
and the percent time that the condition was detected. In particular, the percent 
of time of the last shift that a block was in its normal mode, normal status and 
not limited is illustrated in Fig. 7 as loop utilization. Of course, the screen of 
Fig. 7 could be configured to illustrate the percent of time during the last shift 
that a block was in a non-normal mode, or had a non-normal status or the 
percent of time in the last shift that a function block variable was at one or 
more limits. A measure of variation is shown for the blocks illustrated in Fig. 7 
along with limits therefor. The variability measure in this case is calculated so 
that a value of one is the best case and values greater than one indicate more 
and more variability error. However, using the CI and VI calculations of 
equations (2) and (3) for the variability index will cause the variability index to 
be between zero and one, with zero being the best case. In this case, the 
variability limit should be set to be between zero and one. Furthermore, the 
percent improvement (PI) that is possible in a control loop is illustrated in Fig. 
7 fui control blocks, namely the PIDi block, if desired, the percent utilization 
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values that fall below (or above) the respective limits can be highlighted or 
otherwise marked to indicate the detected problem(s). 

Of course, any other screen display may be used to summarize which 
loops, devices, function blocks or measurements have a high variability index 
(such as being greater than a user specified limit), operate in a non-normal 
mode or have process measurements that have bad or uncertain status or that 
are limited. As noted above, using an historical analysis, the diagnostic tool 52 
may provide displays for a specified time frame to identify devices, loops or 
function blocks that have a variability index, mode, status or limit variable that 
has changed significantly from its normal value. Of course, the diagnostic tool 
52 may enable a user to choose how many and which tests should be used (and 
must be failed) before a process control condition is identified as having a 
problem associated therewith. 

Referring again to Fig. 4, when a user selects one of the function blocks 
in, for example, the display 90 of Fig. 7, a block 93 detects the selection of the 
problem function block and a block 94 displays a set of options to be used to 
correct the problem block or loop For example, for control blocks, the 
diagnostic tool 52 may allow the user to use an autotuner or other tuner to tune 
a loop or may allow the user to perform trend analysis on the loop. By selecting 
the autotuner option, the diagnostic tool 52 automatically finds and executes 
the autotuner application for the selected control block or loop. However, when 
the trend option is selected, the workstation 13 will begin to collect trending 
data as describe hereinafter. 

For input or an output function blocks, the block 94 may allow the user 
to, for example, use a further diagnostic tool for that block or to perform trend 
analysis. If, for example, the selected input or output block is within a Fieldbus 
or Hart device, then selecting the diagnostics option will activate the diagnostic 
application for the associated transducer block using tools known in the art 
such as any device calibration toois. in a DeitaV environment, the asset 
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management solutions (AMS) diagnostic tool manufactured and sold by 
Fisher-Rosemount can be used for this purpose to communicate with a device, 
to obtain specific information therewith and to implement diagnostics 
associated with the device. Of course, other tools or recommendations could be 
made as well. For example, for transmitter problems, or function blocks 
associated with transmitters, the block 94 may recommend that a device 
calibration be used to calibrate the transmitter while, for a valve, any of the 
valve diagnostic routines can be used to detect and possibly correct the specific 
problem within the valve. Generally speaking, the recommendations made by 
the block 94 may be determined based on whether the problem falls into one of 
a number of predetermined types of problems, the nature or identity of the 
source of the problem (e.g. whether it originated in a control or input function 
block, a transmitter or a valve, etc.) or any other desired criteria. Of course, 
any desired diagnostic tools can be used, including those now known or those 
developed in the future. 

If the specific nature of the problem is not easily detected from the 
variability, status, mode, limit or other data that pointed to the existence of a 
problem, the block 94 can recommend the use of other, more complex 
diagnostic tools, such as plotting routines, correlation (such as auto-correlation 
and cross correlation) routines, spectrum analysis routines, expert analysis 
routines or any other desired routine or tools provided for the process control 
system 10. Of course, the diagnostic tool 52 may recommend or suggest the 
use of more than one tool and allow the operator to choose which tooi should 
be used in any situation. Furthermore, the block 94 may limit its suggestions to 
tools actually available within the process control network 10, e.g., those 
loaded onto the operator workstation 13, or may suggest tools that would have 
to be purchased or loaded into the process control system 10 before being used. 
Of course, the block 94 can also suggest the use of manual tools, i.e., those 
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which are not run on the operator workstation 13, controller 12 or one of the 
devices 15-28. 

After the block 94 recommends one or more further diagnostic tools, a 
block 96 waits for a user to select a tool for implementation, and, upon 
receiving such an instruction from the operator, a block 98 finds and executes 
the selected tool to enable the operator to further analyze and pinpoint the 
cause of the problem or to fix the problem. After implementing the diagnostic 
tool, a block 100 enables the operator to select a different tool for the selected 
problem and a block 102 enables the operator to select a different problem. 

In one embodiment, the block 94 can recommend analysis tools typically 
referred to as trending applications that require the collection of a relatively 
large amount and/or a lot of samples of data before being able to be run. 
Examples of such trending applications include a correlation analysis, a neural 
network, a fuzzy logic control procedure, an adaptive tuning procedure, a 
spectrum analysis routine, etc. Unfortunately, when the diagnostic tool 52 
detects problems, the data required for the trending tool is typically unavailable 
because this data was not previously collected. This data may be needed to be 
collected at a high frequency data rate that is not practically achievable using 
simple communications between the controller 12 and the workstation 13. As a 
result, when the operator selects a tool that requires the collection of this data 
(fast data), the block 98 may automatically configure the controller 12 to 
collect the necessary data from the process control system 10. 

When such data needs to be collected from Fieldbus function blocks or 
devices, i.e., from the devices via the Fieldbus bus, the controller 12 may use 
one or more Fieldbus trend objects to collect the data, may bundle and store the 
collected data as packets of data, and may then send the packets of data to the 
operator workstation 13 at any desired time so that the fast data is delivered to 
the operator workstation 13 in a non-time critical manner. This operation 
reduces the communication load between the controller 12 and the operator 
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workstation 13 for the collection of this data. Typically, a trend object is set up 
to collect a predetermined number of samples (e.g., 16) of any desired data 
pertaining to a function block and, when the predetermined number of samples 
has been collected, these samples are communicated to the controller 12 using 
asynchronous communications. The use of one or more trend objects 110 for 
Fieldbus function blocks is illustrated in Fig. 8. The trend object(s) 1 10 are 
used to collect and send desired data to the data collection device 48 within the 
controller 12 and originate within the actual function blocks down within the 
Fieldbus devices. These trend objects 110 may be provided by the Fieldbus 
device or by the shadow function blocks (illustrated generally as shadow 
function blocks 1 12S in Fig. 8) within the controller 12. Similarly, for function 
blocks located within and executed by the controller 12 (illusnated generally as 
function blocks 1 13 in Fig. 8), virtual trend objects 1 14 can be set up within the 
controller 12 to collect the desired data delivered from the 4-20 ma (or other 
devices). Samples for such virtual trend objects 114 may be collected at any 
desired rate, such as eveiy 50 milliseconds. The virtual trend objects 114 may 
be configured to be similar to the actual trend objects of the Fieldbus protocol 
and are delivered to the data collection device 48. The data collection device 
48 delivers the collected data to the data historian 50 within the operator 
workstation 13 as noted above. 

The trend objects 1 10 and 1 14 are collected until enough data has been 
stored to run the desired diagnostic tool. After enough fast data has been 
collected, the block 98 of Fig. 4 executes or otherwise implements the further 
diagnostic tool using the collected data so as to perform high level processing 
and loop analysis. 

One further operation that may be performed by the diagnostic tool 52 is 
to compute the economic effect of using advanced control, such as using 
multi-variable control blocks or loops over standard control, such as 
siiigle-inpui/singie-output control blocks or loops. While the variability, 
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performance, optimality, constraints and utilization indexes described above 
may be used to perform diagnostics and evaluation, in that these variables 
indicate the state of a process and show the areas of improvement within a 
process to technical personnel, it is more important for management personnel 
to have current insight into plant economic performance. In particular advanced 
control applications are justified primary by economic return and, therefore, a 
current measure of this return may be useful or extremely important in making 
decisions to upgrade process control to use advanced control routines or 
procedures. 

Some of the information that may be useful in determining economic 
performance includes yield and throughput increase and profit results from 
increased yield and throughput. 

To calculate these values, a user may associate the expected benefit in 
yield and throughput increase with one or more process variables and enter a 
coefficient or expression which relates the benefit with process variable. After 
the user has entered these values, the diagnostic system can apply formulas 
below to calculate production benefits: 

Yield Improvement = K M-^^W, -X t , u/ ) (12) 
Throughput Improvement = 7'fl - (X, - X olJ ) (13) 

Wherein: 


Y 


a coefficient or expression which relates a specific process 
variable (PV) with yield improvement; 
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T = is a coefficient or expression which relates a specific PV 
with throughout improvement; 

Sapc = PV standard deviation with the advanced control 
procedure such as a multi-variable control procedure; 

Stot = PV standard deviation with previous control procedure; 
X L = PV limit value; and 

^old = PV average value with previous control. 

All these parameters, except Y and T can be made available to the diagnostic 
tool 52 by processing the existing function block parameters as described 
above. 

Of course, the calculations of dollar values resulting from yield and 
throughput improvement requires the user to enter a function relating dollar 
values with a unit rise in yield or throughput improvement. Also, improvements 
in quality and energy savings from the use of new types of advanced control 
procedures could be calculated in a similar manner. 

While the diagnostic tool 52 has been described as being used in 
conjunction with Fieldbus and standard 4-20 ma devices, it can be implemented 
using any other external process control communication protocol and may be 
used with any other types of function blocks or devices having function blocks 
therein. Moreover, it is noted that the use of the expression "function block" 
herein is not limited to what the Fieldbus protocol or the DeltaV controller 
protocol identifies as a function block but, instead, includes any other type of 
block, program, hardware, firmware, etc., associated with any type of control 
system and/or communication protocol that can be used to implement some 
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process control function. While function blocks typically take the form of 
objects within an object oriented programming environment, this need not be 
case. 

Although the diagnostic tool 52 described herein is preferably 
implemented in software, it may be implemented in hardware, firmware, etc., 
and may be implemented by any other processor associated with the process 
control system 10. Thus, the routine 60 described herein may be implemented 
in a standard multi purpose CPU or on specifically designed hardware or 
firmware as desired. When implemented in software, the software routine may 
be stored in any computer readable memory such as on a magnetic disk, a laser 
disk, or other storage medium, in a RAM or ROM of a computer or processor, 
etc. Likewise, this software may be delivered to a user or a process control 
system via any known or desired delivery method including, for example, on a 
computer readable disk or other transportable computer storage mechanism or 
over a communication channel such as a telephone line, the Internet, etc. 
(which are viewed as being the same as or interchangeable with providing such 
software via a transportable storage medium). 

In the present specification "comprise" means "includes or consists of 
and "comprising" means "including or consisting of. 


CLAIMS 
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1. A diagnostic tool for use in a process control system having a 
multiplicity of function blocks wherein one of the multiplicity of function 
blocks is a multi-variable function block, the diagnostic tool comprising: 

a data collection unit configured to communicate with each of the 
multiplicity of function blocks including the multi-variable function block to 
receive at intervals, which may be on a regular basis, during operation of the 
process control system, data pertaining to a function block operating parameter 
for each of the multiplicity of function blocks; 

a data analyzer that determines a value for the function block operating 
parameter for each of a number of times during operation of the process control 
system based on the received function block operating parameter data; 

a detector that detects a problem within the process control system based 
on the determined values of the function block operating parameter; and an 
output generator that creates a report indicating the detected problem. 

2. The diagnostic tool of claim 1, wherein the function block operating 
parameter is a variability parameter and wherein the data analyzer determines a 
variability value associated with the multi-variable function block at each of the 
number of times based on the collected function block operating parameter 
data. 

3. The diagnostic tool of claim 2, wherein the detector compares the 
variability value with a variability limit to detect the problem. 

4. The diagnostic tool of claim 2 or claim 3, wherein the multi-variable 
function block has multiple inputs and wherein the data analyzer determines an 
initial variability index associated with each of the multiple inputs and 
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computes a final variability index as the variability value based on the initial 
variability indices. 

5. The diagnostic tool of any one of claims 2 to 4, wherein the function block 
operating parameter data received from each of the function blocks includes a 
first variability indication indicative of an actual total standard deviation of a 
function block parameter and a second variability indication indicative of a 
capability standard deviation associated with the function block parameter. 

6. The diagnostic tool of claim 5, wherein the data analyzer combines the 
first variability indication with the second variability indication to produce one 
of the initial variability indices. 

7. The diagnostic tool of claim 1, wherein the function block operating 
parameter is a mode parameter and wherein the data collection unit receives a 
mode indication from the multi-variable function block. 

8. The diagnostic tool of claim 1, wherein the function block operating 
parameter is a mode parameter, wherein the multi-variable function block has 
multiple inputs or outputs and wherein the data collection unit receives a mode 
indication for each of the inputs or outputs of the multi-variable function block. 

9. The diagnostic tool of claim 8, wherein the data analyzer determines a 
final mode value for the multi-variable function block specifying if any one of 
the mode indications is a non-normal mode. 

10. The diagnostic tool of claim 1, wherein the function block operating 
parameter is a status parameter, wherein the multi-variable function block has 
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multiple inputs and wherein the data collection unit receives status indications 
for each of the inputs or outputs of the multi-variable function block. 

11. The diagnostic tool of claim 10, wherein the data analyzer determines a 
final status value from the status indications indicating if any one of the status 
indications is a non-normal status. 

12. The diagnostic tool of claim 1, wherein the function block operating 
parameter is a limit parameter, wherein the multi-variable function block has 
multiple inputs or outputs and wherein the data collection unit collects limit 
indications associated with the inputs or outputs of the multi-variable function 
block. 

13. The diagnostic tool of claim 12, wherein the data analyzer determines a 
final limit value from the limit indications indicating if any one of the inputs or 
outputs of the multi-variable function block is at a limit. 

14. The diagnostic tool of any one of the preceding claims, wherein the data 
collection unit further collects an application state parameter from the 
multi-variable function block and wherein the detector ignores the function 
block operating parameter data associated with the multi-variable function 
block to detect the problem when the multi-variable function block operating 
parameter data is associated with a time in which the application state 
parameter was in a first state and the detector uses the function block operating 
parameter data associated with the multi-variable function block to detect the 
problem when the function block operating parameter data is associated with a 
time in which the application state parameter was in a second state. 
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15. A diagnostic tool for use in a process control system that includes a 
processor and that uses a multiplicity of function blocks including at least one 
multi-variable function block to control a process, the diagnostic tool 
comprising: 

a computer readable memory; and 

a routine stored on the computer readable memory and adapted to be 
implemented on the processor, wherein the routine; 

collects at intervals, which may be on a regular basis, data pertaining to a 
function block operating parameter for each of the multiplicity of function 
blocks including the multi-variable function block during operation of the 
process; 

determines a value for the function block operating parameter for each 
of a number of times during the operation of the process control system based 
on the collected function block operating parameter data; 

detects a problem within the process control system based on the 
determined values of the function block operating parameter; and 

produces a report that lists the detected problem. 

16. The diagnostic tool of claim 15, wherein the function block operating 
parameter is a variability parameter, wherein the multi-variable function block 
has multiple inputs and wherein the routine collects variability indications for 
each of the multiple inputs of the multi-variable function block. 

17. The diagnostic tool of claim 16, wherein the routine determines a 
variability value for the multi-variable function block from the variability 
indications collected from the multi-variable function blocks and compares the 
variability value to a variability limit to detect the problem. 
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18. The diagnostic tool of claim 15, wherein the function block operating 
parameter is a mode parameter, wherein the multi-variable function block has 
multiple inputs or outputs and wherein the routine collects mode indications for 
each of the multiplicity of inputs or outputs of the multi-variable function 
block. 

19. The diagnostic tool of claim 15, wherein the function block operating 
parameter is a status parameter, wherein the multi-variable function block has 
multiple inputs or outputs and wherein the routine collects status indications for 
each of the multiplicity of inputs or outputs of the multi-variable function 
block. 

20. The diagnostic tool of claim 15, wherein the function block operating 
parameter is limit parameter, wherein the multi-variable function block has 
multiple inputs or outputs and wherein the routine collects limit indications 
associated with each of the inputs or outputs of the multi-variable function 
block. 

21. A diagnostic tool as described herein with reference to the 
accompanying drawings. 


